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REMARKS 

This Amendment is filed in response to the Office Action of October 15, 2009. The 
amendment filed July 9, 2009 is repeated above without change. The remarks which follow 
are changed to address the obviousness rejection which was inadvertently omitted in the 
amendment filed July 9, 2009. 

I. Amended claims 

The following amendments have been performed in the claims: 

• All independent claims 1 , 45, 46, 64, 69 and 70 have been redrafted based on the 
feature of original claims 19 and 34. 

• The dependent claims have been amended accordingly. 

• New dependent claims 71-74 have been added based on original claim 3. 

II. Subject-matter of the present invention 

The present invention, as expressed by the amended independent claims, relates to conveying 
parameters for broadcast/multicast sessions via communication protocol. A repair type 
parameter that is indicative of a point-to-multipoint repair session, a point-to-point repair 
session or both is received. The repair session is requestable by at least one receiver that did 
not correctly receive data sent to a plurality of receivers in a transmission session, wherein in 
the repair session, at least a part of the data sent to the plurality of receivers in the 
transmission session is sent at least to the at least one receiver requesting the repair session. 
Data is then received in the repair session as indicated by the repair type parameter. 

Being able to select among different kinds of repair sessions - i.e. point-to-multipoint repair 
sessions, point-to-point repair sessions or both - and communicating this specific kind of 
repair session to receivers via a repair type parameter is particularly useful at least for the 
following reasons: 

- In case of many receivers suffering from data corruption during the 

broadcast/multicast transmission session, re-transmission of the corrupted data in a 
single point-to-multipoint repair session may be more efficient than having a plurality 
of point-to-point repair sessions. Nevertheless, if there are only one or few receivers 
suffering from data corruption, having dedicated point-to-point repair sessions may 
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allow tailoring the re-transmitted data to the respective needs of the receivers, which 
may result in an overall reduced amount of data that has to be re-transmitted (i.e. the 
single receivers only receive that data that they actually require). 
- Signalling that a point-to-multipoint repair session will take place may prevent further 
receivers that did not correctly receive the multicast data and did not yet send a request 
for a repair session from sending this request for a repair session, thus contributing to 
reduce network congestion by a plurality of repair requests. 

III. Prior art 

RFC 2327 - SDP: Session Description Protocol, April 1998 (Handley etal) 

This document defines the SDP. SDP is intended for describing multimedia sessions for the 

purposes of session announcement, session invitation, and other forms of multimedia session 

initiation. 

US 2004/0078624 {Maxemchuk et al) 

Maxemchuk et al. relates to a system and method for the repair of IP multicast sessions. A 
network includes a source of multicast packets in a multicast session and a plurality of 
multicast recipients. The repair server provides the packets it receives to the recipients. The 
repair server includes a missing packet detector. There is a plurality of retransmit servers in 
the network buffering portions of the packets they respectively receive during the session. The 
repair server maintains an ordered list of the retransmit servers that are most likely to have 
buffered copies of packets missing from the session. When the repair server detects that there 
are packets missing from the session it received, it uses the ordered list to sequentially request 
the missing packets from respective ones of the plurality of retransmit servers (see the abstract 
and paragraphs [0010-0015]). 

US 2003/0120802 Al (Kohno etal.) 

Kohno relates to a data communication system, in which the function of automatic repeat 
request is provided for transmission of packets based on a data communication protocol such 
as the Real-Time Transport Protocol or the User Datagram Protocol. Lost packets are detected 
at various timings, for example, when the beginning packet of each frame is received, the 
final frame of each frame is received, at a time limit of processing, and at a regular interval, 
and retransmission requests are issued accordingly. A data reception terminal does not issue a 
retransmission request if associated retransmission data will not be in time for playing with 
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consideration of processing time and roundtrip time, thereby avoiding the transmission of 
useless retransmission request packets and retransmission packets. 

"Optimally selecting the parameters of adaptive backoff algorithms for computer 
networks and multiprocessors" by Peter B. Danzig (Danzig) 

In his dissertation, Danzig relates to a multiple round multicast algorithm. Thereby, the sender 
chooses a round's timeout based on the number of outstanding responses of the recipients of 
the multicast, its buffer service time distribution, and a criterion that the multicast completes 
by the last round. The sender calculates a backoff value, which is transmitted to the recipients 
of the multicast and which can be used by the recipients to randomly delay their responses. If 
the sender fails to receive all of the responses of the recipients before the calculated timeout, it 
may need to retransmit the multicast. Once it is accepted that retransmissions are inevitable 
and explicitly chosen to transmit more than once, this procedure may significantly reduce a 
multicast 's total latency. 

IV. Novelty and non-obviousness of the amended independent claims 

1 . In the Office Action of January 1, 2009, the Examiner argues that the subject-matter of the 
independent claims is rendered obvious by Khono in view of Danzig. Irrespective whether 
this finding is true, it is respectfully submitted that the subject-matter of the presently 
amended independent claims is novel and non-obvious over Khono and Danzig. 

Firstly, Khono clearly relates to a system where data, for instance motion data, is transferred 
from one sender terminal to one receiver terminal (e.g. see paragraph [0067]: the sender 
terminal to the receiver terminal) and, if transmitted data is corrupted, a retransmission of the 
data may be initiated. Thus, Khono may only be considered to disclose an advanced automatic 
repeat request (ARQ) function for a point-to-point transmission session. Thereby, if 
necessary, data is retransmitted in a point-to-point repair session. 

Since Khono does neither disclose a point-to-multipoint transmission session nor a point-to- 
multipoint repair session nor a repair type parameter, the subject matter of the amended 
independent claims is novel with respect to Khono, and it is also not apparent how Khono 
should render the subject-matter of the amended independent claims obvious (particularly, the 
transmission of a repair type parameter that is indicative of a point-to-multipoint repair 


11 


915-007.082 
Serial No. 10/806,023 


session, a point-to-point repair session, or both and the transmission of data in the repair 
session as indicated by the repair type parameter). 

Secondly, Danzig may be considered to disclose a multicast is transmitted from a sender to a 
plurality of receivers (see page 54, section 3.8: we propose a multiple round multicast 
algorithm), and that the multicast can be re-transmitted (in a kind of repair session, see page 
13, first paragraph). Danzig however fails to disclose that the repair session can be point-to- 
point, point-to-multipoint or both, and that a repair type parameter is transmitted that indicates 
the specific type of the present repair session (point-to-point, point-to-multipoint or both). 

Furthermore, Danzig obviously only discloses a communication system where a receiver has 
to positively acknowledge the successful reception of transmitted data (ACK), whereas the 
present invention is based on negative acknowledgments (NACKs), as reflected by the claim 
feature that "a repair session is requestable by at least one receiver that did not correctly 
receive data". In other words, the amended independent claims require a receiver to actively 
request a repair session (for instance by sending a NACK), wherein in Danzig, only failure to 
receive ACKs from all receivers within a specific period of time leads to a repair session 
taking place. 

Thus, the subject-matter of the amended independent claims is also clearly novel and non- 
obvious with respect to Danzig. 

2. In the Office Action of January 23, 2008, section 9 on p. 28, the Examiner considers the 
subject-matter of original claim 34 to be rendered obvious by a combination of SDP and 
Maxemchuk. It appears that this finding is based on the Examiner's assertion that the ordered 
list of retransmit servers maintained at the repair server would disclose as repair type 
parameter. 

This view has to be respectfully contested. 

Maxemchuk may be considered to disclose that data packets are transmitter from a sender to a 
plurality of receivers, and to disclose presence of a repair server. However, in Maxemchuk, 
the receivers can select by means of different multicast addresses if they want to take part in a 
standard session, in which data packets are provided by a multicast source without repair 
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functionality, or a repair session, in which the data packets also stem from the multicast 
source, but are provided via the repair server that automatically tries to obtain lost packets 
from a plurality of retransmit servers and to provide them to the plurality of receivers (see 
paragraph [0013]). The repair server thus improves the multicast data transmission as a 
network supplied service, and neither the source nor the receivers see any change (see 
paragraph [0012]). 

Maxemchuk thus already fails to disclose that a repair session is requestable by at least one 
receiver that did not correctly receive data sent to a plurality of receivers in a transmission 
session , as required by the amended independent claims. In Maxemchuk, a receiver can take 
part in either an "unrepaired multicast session" or a "repaired multicast session" (see 
paragraph [0013]), whereas in case of the latter option, the repair session is not after the actual 
transmission session, but in parallel, i.e. to enhance the transmission session. 

Maxemchuk further entirely fails to disclose point-to-point repair sessions. Both the 
"unrepaired multicast session" and the "repaired multicast session" are always described as 
multicast sessions. 

And finally, Maxemchuk also fails to disclose a repair type parameter that indicates a point-to- 
multipoint repair session, a point-to-point repair session, or both. This is already caused by 
the lack of disclosure of a point-to-point repair session. Furthermore, there is not even a 
parameter that would indicate a point-to-multipoint repair session alone, and in particular no 
such parameter that would be transmitted to the receivers. 

It is thus apparent that the amended independent claims are novel and non-obvious with 
respect to Maxemchuk . 

3. Applicants admitted prior art (AAPA) does not relate to repair sessions at all, and, hence, 
neither a point-to-point repair session nor a point-to-multipoint repair session nor a repair type 
parameter indicating the type of the repair session is disclosed therein. Thus, the amended 
independent claims are novel and non-obvious with respect to AAPA. 

4. Lastly, it is also not apparent how a combination of the cited prior art should render the 
subject-matter of the amended independent claims obvious, since the prior art already entirely 
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fails to disclose that it is advantageous to be able to switch between point-to-multipoint and 
point-to-point repair sessions. 


FJM/mo 

WARE, FRESSOLA, VAN DER SLUYS 

& ADOLPHSON LLP 
755 Main Street, P.O. Box 224 
Monroe, Connecticut 06468 
(203) 261-1234 
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